ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/tsql/doc/tsql.mail/[e-mail] _Thu Apr 22 17:10:17 1993.msg

Internet Message Format | 1996-01-31 | 5KB

Received: from IS-4.STERN.NYU.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
    id AA23285; Thu, 22 Apr 1993 14:02:33 MST
Received: by is-4.stern.nyu.edu (4.1/1.34)
    id AA18226; Thu, 22 Apr 93 17:10:20 EDT
Date: Thu, 22 Apr 93 17:10:17 EDT
From: Jim Clifford <[e-mail]>
To: [e-mail]
Subject: Benchmark Instance
Cc: [e-mail]
Message-Id: <[e-mail]>

Here are what I hope will be my final comments with respect to the
contents of the benchmark database.

I disagree with Rick's recent suggestion that we not address,
forthrightly, the issue of grouped and ungrouped temporal data models
at this point in time. Here are my reasons:

(1) the distinction between these two approaches is a fundamental,
structural distinction that has been known, though perhaps not
well-understood, for a really long time. Every model can be placed
into one or the other of these two types. For too long people have
thought that they were equivalent approaches to the same problem.

(2) It has been suggested that the lack of a treatment of other
temporal aspects of data, such as (i) transaction time, (ii) future
valid times, and (iii) continuous attributes such as temperature is
comparable to the lack of a treatment of the issue of grouping. I think
this is an incorrect comparison, since ALL of these features COULD be
added to either type of model. These are not really structural aspects
of the model so much as they are additional features.

Since there are so many of us involved in the workshop --- and in the
temporal fdatabase community at larger --- who have invested a lot of
energy in developing theories of data models with built-in support for
what we have called "temporal grouping", I think it would be
inappropriate to exclude at least some data in the proposed benchmark
that reflects the strength of this approach.

Rick lists 4 specific "disadvantages" to dropping the constraint that,
as he puts it, "keys in the instance are time-invariant." I do not
find these compelling objections in the face of the importance of this
issue.  I have one comment on the 4th objection, having to do with
grouping and surrogates.

It seems to me that if an issue is sufficiently important, it should
be incorporated into the model. That, after all, is the whole argument
for temporal databases. The issue which we have called "grouping" is
patently important in both types of models.  The issue is, in fact, one
of who supports the grouping. In the ungrouped models, the USER must
support the grouping by explicitly including the key attribute(s) in
every query.  In the grouped models, the model explicitly supports the
grouping and frees the user from any burden.


So, my recommendation remains that we modify the Proposed Data to
include the following in the subsection entitled "The Proposed Data":

Three instances, {\tt emp}, {\tt skills}, and {\tt mgr}, are defined
over the {\tt Emp}, {\tt Skills}, and {\tt Mgr} relation schemas,
respectively. The contents of these instances is described below.

There are two employees, *ED* and *DI*.

*ED* worked in the Toy department from 2/1/82 to 1/31/87, and in the
Book department from 4/1/87 to the present.  His name was "Ed" from
2/1/82 to 12/31/87, and "Edward" from 1/1/88 to the present.  His
salary was \$20K from 2/1/82 to 5/31/82, then \$30K from 6/1/82 to
1/31/85, then \$40K from 2/1/85 to 1/31/87 and 4/1/87 to the present.
*ED* is male and was born on 7/1/55. Several skills are recorded for Ed.
He has been qualified for typing since 4/1/82 and qualified for filing
since 1/1/85. He was qualified for driving from 1/1/82 to 5/1/82 and
from 6/1/84 to 5/31/88.

I am happy to leave the descriuption of *DI* as is.

The exact content of the database instance that would attempt to model
this English language description of the reality of an enterprise
will, of course, depend upon the specifics of the data model. The
answer to any queries that might be included in the proposed set of
queries would, likewise, differ from model to model.

I welcome comments.

--jim--

************************************************************************
Jim Clifford                                     [e-mail]
Associate Professor                              TEL: [phone]
Department of Information Systems                FAX: [phone]
Leonard N. Stern School of Business
New York University
Management Education Center
44 West 4th Street, Suite 9-74
New York, NY 10012-1126
************************************************************************